The present invention relates to computer operating systems, and more specifically relates to a method and apparatus for client/server translation and execution of non-native applications.
It is important, given the investment most users have in their applications software, that an application be usable with several different operating systems. However, this is difficult to achieve in practice due to the myriad of differences between the different operating systems (e.g. different internal design architectures, different process structures, different memory management, different exception and error handling, different resource protection mechanisms, etc.).
To help address this problem, operating system vendors provide support in a number of ways for different operating system environments. For example, IBM OS/2 version 2.0 (hereinafter simply xe2x80x9cOS/2xe2x80x9d) runs applications written for Windows 3.1 (a xe2x80x9cnon-native applicationxe2x80x9d) by providing an environment for the application that mimics the Windows 3.1 environment.
In more detail, when OS/2 receives a request to run a Windows 3.1 application, it creates a process called a virtual machine (VM). The VM contains the Windows 3.1 application program and all the Windows 3.1 operating system components needed to support execution of Windows 3.1 applications. This process is repeated for each non-native application run under OS/2 (i.e. a separate VM containing a complete copy of all the operating system components needed to support the non-native application is spawned for each).
There are several problems associated with this replicate-a-non-native-OS-in-a-VM approach. One is its ineffective and wasteful use of resources. Windows 3.1 is a relatively old (in computer terms) 16-bit operating system. OS/2 is a newer 32-bit operating system that includes all of the functionality of older 16-bit operating systems, and provides additional capabilities as well. The provision of components from the older 16bit Windows 3.1 operating system inside each VM spawned by the more modern 32-bit OS/2 operating system for a Windows 3.1 application is an unartful way to provide compatibility; the resources of the 32-bit operating system are essentially wasted.
A further drawback of this approach is that non-native applications running in separate VMs can""t readily xe2x80x9cseexe2x80x9d each other (e.g. communicate or exchange data). For example, dynamic data exchange (DDE) and object linking and embedding (OLE) between applications executing in separate VMs is difficult, if possible at all. (Such data exchange between applications is important in order to achieve seamless integration between applications. An illustrative case is a user who wants to link a chart from a spreadsheet program into a word processing document, where each time the chart is updated in the spreadsheet program, the chart in the word processing document is likewise updated.) Under OS/2, such seamless integration cannot be achieved.
Yet another problem is that, when a non-native application executes, the non-native video driver in its VM takes control of the computer""s video display hardware (and sometimes other hardware) from the OS/2 operating system. This results in xe2x80x9cblacking outxe2x80x9d of the existing OS/2 native user interface, and, a moment later, the presentation of a different user interface associated with the non-native application. Some users find the total loss of the familiar OS/2 interface to be a considerable inconvenience.
Alternatively, the OS/2 video device driver can be modified to present the OS/2 user interface over most of the screen, but surrender control of a rectangular window (a xe2x80x9cblack holexe2x80x9d) to a non-native video device driver associated with a VM. These two concurrently executing video device drivers must cooperate so that neither interferes with regions of the display allocated to the other driver. This cooperation between 16-bit and 32-bit video device drivers is difficult at best, and becomes extremely complicated when several VMs are overlapped on the display screen. The modifications to the OS/2 device drivers sometimes lead to unexpected behavior since they interfere with the device driver""s original design.
In accordance with a preferred embodiment of the present invention, problems associated with this replicate-a-non-native-OS-in-a-VM approach are overcome. An operating system with a client/server architecture including a set of specially modified server processes called modified virtual machines (MVMs) is provided. In client/server operating systems, such as Windows-NT by Microsoft, xe2x80x9cclientsxe2x80x9d are processes that request services, e.g. file service, memory management, etc. (Clients are often, but are not necessarily, applications programs.) xe2x80x9cServersxe2x80x9d are processes that provide services. Communications between client and server processes are handled by an operating system xe2x80x9ckernel.xe2x80x9d
When an individual server process MVM is created, only the essential xe2x80x9ckernelxe2x80x9d components of the non-native operating system are copied into the MVM (i.e. essential, non-replaceable device drivers, interrupts, etc.). Other operating system support required by the non-native (16-bit) application is provided from the native (32-bit) operating system through a translation procedure (xe2x80x9cthunkingxe2x80x9d). For example, if the non-native (16-bit) application requests services such as user interface (UI), graphics device interface (GDI), DDE, OLE, etc., the service request is automatically thunked into the corresponding native (32-bit) service request and passed to the native (32-bit Windows-NT) operating system. The native operating system services the request and passes any return data through the thunking process and back to the originating non-native application. By this arrangement, all MVMs make shared use of a common set of native operating system functions, gaining the enhanced functionality of the native (32-bit) services, and facilitating communication and data sharing between applications.
This arrangement also allows the native operating system to maintain exclusive control over the video display and other hardware. The prior art xe2x80x9cblacking outxe2x80x9d and xe2x80x9cblack holexe2x80x9d phenomena are eliminated.
The foregoing and other features and advantages of the preferred embodiment of the present invention will be more readily apparent from the following detailed description, which proceeds with reference to the accompanying drawings.